It is not uncommon for software modules operating on computer systems to require access to shared resources. For example, a given computer program may require access to files maintained by a file system, or it may require access to network connections maintained by a network driver. Network drivers may require access to information structures maintained by a network packet classifier. This is a complex arrangement that includes numerous software modules, such as software drivers requiring access to many shared resources and an access supervisor that either maintains the resources or at least intercedes when a software module attempts to access a resource.
Intercession by an access supervisor is important for several reasons. One especially important reason is associated with a situation when a software module deletes a resource. Specifically, if a first software module deletes a resource, then other software modules that maintain direct pointers to the resource will be unable to access or use the resource. This is because their pointers will no longer point to a valid resource. Attempts have been made to solve this problem by notifying software modules when a resource deletion occurs. However, this requires detailed accounting and tracking of software modules and their respective pointers to the resources. As a result, this process is extremely expensive and very complex.
Another attempt to solve this problem involves having an access supervisor intercede when a software module requires access to a particular resource. Interceding ensures that the particular resource still exists before the software module is granted access to the particular resource. Typically, this is accomplished by having the access supervisor, through a handle administrator, issue a handle to each software module for a particular resource instead of allowing each software module a direct pointer to that particular resource. The handle is associated with the resource and is used to refer to the particular resource when it is desired to be used by the software module. The software module does not use the handle to directly access the resource. Rather, the software module presents the handle to the access supervisor, which can then use the handle to obtain a pointer to the resource for that software module. The process of converting a handle for a resource into a pointer to that resource is known as dereferencing.
Handle administration systems are typically characterized by having handles that can assume one of two states—an assigned state and an unassigned state. When a handle is in the assigned state, the handle administrator has associated that handle with both a resource and a pointer to the resource. The handle can then be used by software modules any time they want to obtain a pointer to the resource. To obtain a pointer to a resource, the software modules simply present the handle to the access supervisor which then checks to determine whether the handle is valid. If the handle is valid, then the associated pointer to the resource can be returned to the software module. If the handle is not valid, then an appropriate notification to the software module can be generated. When a handle is in the unassigned state, it is not associated with any resource and thus cannot be used to access a resource. An assigned handle becomes unassigned when it is “released”. A handle can be released when the resource with which it is associated is removed or is no longer available for use by the software modules. Releasing a handle means that the handle can no longer be used to access the resource with which it was formerly associated. Once a handle is released, it is available to be associated with another resource and thereby returned to the assigned state.
It would be very desirable, in some situations, to have the ability to tentatively release a handle. Such a tentatively released handle is still associated with a resource, but it is not considered valid, so it cannot be dereferenced to obtain a pointer to the associated resource. Because the tentatively released handle is not fully released, it is not available to be associated with another resource. This tentatively released handle could then be permanently released into an unassigned state, thus making it available for assignment to another resource, or it could be reinstated into an assigned state that maintains its association with the resource with which it has already been assigned. Presently, however, there are no known handle administration systems that allow this kind of operation.
Accordingly, this invention arose out of concerns associated with improving handle administration systems and methods.